urldecoded URL rewrites grid custom columns #186
Conversation
|
Regarding the need to re-use Also, you may want to remove the possibility for the user to choose the rendering of the column, because the only relevant and/or compatible choice seems to be "Text". Two ways of doing :
|
Also created grid type for URL rewrites grid, and setup urldecoded renderer for request and target path custom columns.
mwgamble
force-pushed
the
urldecoded_urlrewrite_grid_columns
branch
from
47e708a
to
3f33907
Compare
There's no need to allow custom renderers for these columns, as we need to force urldecoding of the values.
This block ensures the field is properly URL-encoded when filtering. It properly accounts for URL paths that have query strings and multiple path segments too.
mwgamble
force-pushed
the
urldecoded_urlrewrite_grid_columns
branch
from
92e692c
to
8ae31cb
Compare
|
Hi, just wanted to let you know that I've finally got around to updating this pull request to use a custom filter block. I'd appreciate your thoughts on any potential improvements. While I was working on this, I realised that slashes in URL paths were being encoded, meaning any searches involving slashes wouldn't return anything. The solution to this was to break up the path and encode each component of the URL path, as per this stackoverflow answer: http://stackoverflow.com/a/7973896/ |
We ran into an issue recently where we had a need to create URL keys for products and categories with non-Latin characters, and they were not showing up properly in the URL rewrites grid. The URL keys are stored in the database in their encoded form with all of those ugly percent signs, and only decoded when they need to be displayed. We utilised EAG custom columns to achieve this in the URL rewrites grid.
This adds custom columns for the URL rewrites grid that urldecode ID, request and target paths when viewing them. In order to allow filtering with these non-Latin characters, we also have to add a custom filter class which encodes the value entered by the user.
As you can see from the third commit, currently we have to set the value on the filter object, then get the condition array, then set it back to the decoded version again. It would be nice if we could just pass the encoded version to the
getCondition()method to avoid having to do this. Could you advise on whether we missed something, or if we should be going about this differently?